Most computers and other digital systems have a system memory which often consists of dynamic random access memory (“DRAM”) devices. DRAM devices are fairly inexpensive because a DRAM memory cell needs relatively few components to store a data bit as compared with other types of memory cells. Generally a DRAM memory cell consists of a transistor/capacitor pair whereas, in a static random access device (SRAM), each memory cell comprises four or more transistors. Thus, DRAM memory cells have fewer components than SRAM memory cells. As a result, DRAM arrays occupy far less area on a semiconductor substrate compared to SRAM arrays of the same size. Thus, DRAM devices are far less expensive to produce than SRAM devices. A large system memory can be implemented using DRAM devices for relatively low cost, making DRAM devices a very popular choice in many devices requiring a large memory capacity.
On the other hand, while DRAM devices are less expensive to produce than SRAM devices, DRAM devices suffer from the disadvantage that their memory cells must be continually refreshed because of the inherently transitory nature of their storage technology. Over time, the voltage stored across the capacitor dissipates as a result of current leakage. To offset this problem, each memory cell regularly must be refreshed within a maximum refresh interval by determining whether a high or low voltage was stored across that capacitor, and recharging the capacitor to that voltage. The refresh process, which basically involves reading a memory cell through a sense amplifier to recharge the memory cell's capacitor, is well known in the art, and it is reasonably simple and quick.
Notwithstanding how quick the refresh process might be, however, having to continually refresh all the memory cells in a DRAM memory array impedes the intended function of the memory: reading and writing data in response to processor directives. Even though memory cells are refreshed an entire row at a time, memory banks may be thousands of rows deep, and each row must be refreshed many times per second. Collectively, thousands upon thousands of refresh operations are required every second to preserve the contents of the memory cells in a DRAM device—thousands of operations during which the DRAM device is precluded from performing desired read and write functions. Moreover, unless the memory array is equipped with a dual accessing mechanism, a row cache device, or a functionally similar means, the array can be neither read from nor written to during a refresh cycle without interrupting or destroying the cycle. If the central processing unit or other controller initiates a memory read or write operation during a refresh cycle, the processor or controller needs to wait for completion of that refresh cycle along with any corresponding wait states or delay intervals. Clearly, waiting for refresh procedures slows the operational throughput of the computing system.
FIG. 1 depicts a conventional DRAM device 100. The DRAM device 100 is accessed through the address lines 110, the data lines 112, and a number of control lines 120-132. These control lines include CKE (clock enable) 120, CK* (clock signal—low) 122, CK (clock signal) 124, CS* (chip select—low enable) 126, WE* (write select—low enable) 128, CAS* (column address strobe—low enable) 130, and RAS* (row address strobe—low enable). The address lines 110, data lines 112, and control lines 120-132, enable the system to read and write data to the actual memory banks 150, as well as control the refreshing of the DRAM device 100.
The control logic 160 controls the read, write, and refresh operations of the DRAM device 100. The control logic 160 directs the operations of the DRAM device 100 as a function of the signals received at the control lines 120-132. Numerous other elements of the DRAM device 100 are depicted in FIG. 1, but the refresh counter 170 and the self-refresh control logic 180 are particularly relevant to this discussion.
The refresh counter 170 is an integral component in refreshing the DRAM device 100. The refresh counter 170 maintains a count corresponding to the row number in the memory banks 150 that was last refreshed or, if a row refresh is in progress, the number of the row currently being refreshed. Once a command is received to refresh a row, the refresh counter 170 is incremented by one, and the row of the memory banks 150 corresponding to the updated count stored in the refresh counter 170 is refreshed. The refresh counter 170 thereby tracks what row is next to be refreshed, controlling the sequencing of row refreshes.
Tracking the count maintained by the refresh counter 170, the rows of the memory banks 150 can be refreshed in either burst refresh or distributed refresh. Using burst refresh, all the rows of the memory banks 150 are refreshed in immediate succession, one after the other, for as long as it takes to refresh every row of the device. Operationally, the refresh counter 170 is incremented, the row indicated by the refresh counter 170 is refreshed, and this process repeats until each row of the memory banks 150 has been refreshed. Once all the rows have been successively refreshed, the DRAM device 100 once more is available for read and write operations until the memory banks 150 of the DRAM device 100 must again all be refreshed.
In a distributed refresh, one row of the memory banks 150 is refreshed at a time, then the DRAM device 100 is made available for useful operations until the next individual row of the memory banks 150 needs to be refreshed. As the designation “distributed” implies, this type of refresh distributes the time required to refresh every row in the memory banks 150 over the entire maximum refresh interval, instead of ceasing all read and write operations for the relatively long interval required to refresh every row in the memory banks 150 as in a burst refresh. Specifically, for each refresh command received, the refresh counter 170 is incremented, the row corresponding to the number indicated by the refresh counter 170 is refreshed, then the DRAM device 100 is made available for read and write operations until the next refresh command is received. This process repeats continuously. In a typical DRAM, having 4,096 rows and a maximum refresh interval of 64 milliseconds in its operational mode, a command to refresh one row would have to be issued approximately every 15 to 16 microseconds.
In addition, in a typical DRAM device, there are also two different types of refresh modes: auto-refresh and self-refresh. The first type, auto-refresh, is the command given to initiate a single refresh command. Whether the system employs burst refresh or distributed refresh to refresh its memory devices, issuance of an auto-refresh command initiates one refresh cycle for the entire memory bank or for a single row, respectively. Auto-refresh is, therefore, the “standard” refresh command used to refresh memory devices during normal operation. An auto-refresh command is issued to the DRAM device 100 by driving the CKE 120 and WE* 128 control lines high, and driving the CS* 126, RAS* 130 and CAS* 132 control lines low.
Auto-refresh operates synchronously with the system clock. With the CKE 120 and WE* 128 control lines driven high, and the CS* 126, RAS* 130 and CAS* 132 control lines driven low, the rising edge of the next clock signal initiates an auto-refresh of the next row of the memory banks 150. As is known in the art, the rising edge of the next clock signal is that point where the clock signals received at the CK* 122 and CK 124 control lines cross. As previously described, the refresh counter 170 is incremented to indicate the next row in the memory banks 150 that is being refreshed or is next to be refreshed. Between refreshes in a system employing a distributed refresh mode, or once all the rows have been refreshed in a system using a burst refresh mode, the signals applied to the control lines can be driven to the states signaling read, write, and other valid commands. An interval trfc, the time indicated by the device specification, should be permitted after the issuance of the auto-refresh command and the issuance of the next command.
By contrast, issuance of a self-refresh command places a DRAM device 100 in a continual, indefinite refresh cycle to preserve the data stored in the DRAM device 100. A self-refresh command typically is issued during a period when useful read and write requests will not be forthcoming, for example, when a user has placed the computing system into a sleep or standby mode. A self-refresh cycle typically employs a distributed refresh cycle internally.
During a self-refresh cycle, because the system will not be called upon to perform read or write commands, current and voltage switching in the DRAM device 100 is reduced. This relatively stable condition tends to ameliorate electrical and thermal effects which contribute to current leakage from the capacitors of the memory cells. As a result, while the memory cells still need to be refreshed to preserve the integrity of the data stored therein, the memory cells do not need to be refreshed as frequently as during an operational state. During self-refresh, the contents of the memory cells can be preserved by refreshing a row less frequently than every 15 milliseconds as required in this example DRAM device 100. In self-refresh state, the rows might not need to be refreshed for a period up to twice as long, or perhaps slightly longer, than is permitted during an operational state.
A self-refresh command is triggered by driving the CS*126, RAS* 130 and the CAS* 132 control lines low, driving the WE* 128 control line high, and, this time, driving the CKE 120 control line low. This command causes the self-refresh control logic 180 to periodically and repeatedly refresh every one of its rows, and also places all data, address, and control lines into a “don't care” state, with the exception of the CKE 120 control line. The CKE 120 control line being driven high takes the other control lines out of the “don't care” state, and signals the end of the self-refresh state. At that point, after a waiting interval described below, the system can then access the DRAM device 100 for read and write operations and/or to control the refreshing of the DRAM device through auto-refresh commands.
Although a self-refresh state is very similar to a repeating series of auto-refresh states, there is a critical difference: while a DRAM device 100 in an auto-refresh state is refreshed synchronously with the system clock, in a self-refresh state, the DRAM device is refreshed asynchronously and independently of the system clock. During a self-refresh state, the refreshing of the rows of the memory banks is controlled by the DRAM device's own, on-board self-refresh control logic 180. The on-board self-refresh control logic includes its own clocking system (not separately shown in FIG. 1) which pulses the self-refresh cycles, as described, at a less frequent rate than the system clock pulses operational commands.
During self-refresh, the memory banks 150 are refreshed according to the DRAM device's 100 own clock, asynchronously of the system clock during self-refresh. As a result, the system may issue a self-refresh exit command at any point during the self-refresh cycle of the DRAM device 100, either while a row is being refreshed or during a wait state between row refreshes. Accordingly, from the time the self-refresh exit command is issued until the DRAM device is available to process commands, the system must allow a waiting interval to pass. Waiting for this interval to pass will allow for the completion of the self-refresh of a row, if one was in progress as the time the self-refresh exit command was issued. If a self-refresh cycle was not in progress, the self-refresh control logic 180 will halt the self-refresh process and wait to make sure that no new refresh cycle begins once the self-refresh exit command has been received.
This waiting interval is denominated as txsr, to represent the time needed to “exit self-refresh.” In either case, the system will not have any indication of whether a row refresh was in progress at the time the self-refresh exit command was issued, and the system must allow the interval txsr to pass before issuing other commands. The passage of the interval txsr is purely time wasted if a row refresh was not in progress when the exit self-refresh command was issued. Nonetheless, it is a necessary precaution because the self-refresh process operates asynchronously and independently of the system clock. The interval txsr typically is equal to the time required to refresh one row, denominated as trfc, to represent the time to “refresh complete,” plus one additional clock cycle to allow for the asynchonicity between the phase of the DRAM device 100 self-refresh clock and the system clock. Typically, this interval is on the order of 60 to 70 nanoseconds.
Certainly, potentially having to waste time just in case a row self-refresh was in progress is a concern for its own sake. However, a larger concern is the effect the asynchronicity between the self-refresh cycle and the system clock might have on the integrity of data stored in the DRAM device 100. There is a possibility that rows of memory cells in the DRAM device 100 may not be refreshed within the maximum refresh interval and the contents of the memory cells in these rows may become corrupted. As previously described, the relatively stable state of the DRAM device 100 in self-refresh mode reduces current leakage in the DRAM device 100 because no commands are being processed that might cause unpredictable voltage and current fluctuations. Consequently, the maximum refresh interval for a DRAM device 100 in self-refresh mode is longer than that for a DRAM device 100 in operational mode, and the interval between row refresh cycles is also longer. Potential problems arise upon the transition from the relatively stable, slower-refreshing self-refresh state to the more volatile operational state and from the cumulative effect of numerous transitions between self-refresh and operational states.
FIG. 2 illustrates these concerns. The chart 200 visually depicts the switching of a DRAM device over time in response to self-refresh exit commands. Specifically, the device state graph 210 shows how the DRAM device switches between the self-refresh mode 220 and the operational mode 230 in response to receipt of self-refresh and self-refresh exit commands as represented by the switching between low and high states of the CKE signal line as depicted by the CKE signal 240. As previously described, it is assumed that this DRAM device refreshes a row once every 40 microseconds while in self-refresh mode, and once every 15 microseconds while in operational mode. It is also assumed that, just at or prior to time t=0, a row was refreshed during the self-refresh state, incrementing the row counter to indicate the next row must be refreshed in 40 microseconds.
Before the next row is refreshed, however, at approximately time t=35 microseconds, the system issues a self-refresh exit command as represented by the CKE signal 240 driving high at 250. In response, the self-refresh mode 220 is exited as represented by the device state graph 210 exiting self-refresh and returning to operational status 230 at 260. Because the system clock and the DRAM device's on-board self-refresh clock operate asynchronously of each other, the system had no indication that the DRAM device was about to execute a row refresh operation at time t=40 microseconds. As a result, the row refresh operation was not executed, and as the DRAM device resumes the more volatile operational state, current leakage could affect the voltages stored in the memory cells and thereby undermine the integrity of the data stored. If the DRAM device has been in self-refresh mode for at least the time required to complete one complete self-refresh of each row in the DRAM device, assuming the device has 4,096 rows and self-refreshes one row every 40 microseconds, the next row to be refreshed has not been refreshed in nearly 164 milliseconds; this period is more than two and one-half times the maximum refresh interval of the DRAM device in its operational state.
To compound the problem, just before that row was to be auto-refreshed 15 microseconds after the DRAM device returned to its operational state 230, the CKE signal 240 transitions low at 270 to direct the DRAM device back into self-refresh mode 220 at 280. Upon returning to self-refresh mode 220, the self-refresh clock will become active to refresh the next row in 40 microseconds at approximately time t=90 microseconds. However, before that refresh occurs, once more the CKE signal 240 transition high at 290, directing the DRAM device to exit self-refresh mode 220 once again and resume operational status 230. Charge leakage continues, and the integrity of the data stored in the next row of the DRAM device to be refreshed—and the succeeding rows which also have not been refreshed for a growing interval of time—becomes even more questionable.
This example, wherein the self-refresh mode is exited, entered, and exited again so rapidly is a somewhat extreme illustration for the sake of highlighting the problem. Notwithstanding, in an era presently becoming increasingly dominated by gigahertz-clocking devices and increasingly larger DRAM devices with thousands upon thousands of rows of memory cells to be refreshed, actual loss of memory contents upon mode changes is a very real concern. This is particularly true if the DRAM devices are used in slower-clocking systems where auto-refresh commands may be issued even less frequently.
At present, there is one predominant solution to the problem of one or more rows not being refreshed in a timely fashion as a result of a DRAM device switching between self-refresh and operational modes. Specifically, this solution is the standard observed by the Joint Electron Device Engineering Council (JEDEC). The JEDEC standard suggests that, upon issuing the command to exit the self-refresh mode, and after the self-refresh mode has exited but before the system issues any other commands, the system should be programmed to first issue an auto-refresh command. This solution addresses the problems described previously in that the next row of memory is immediately refreshed upon exiting self-refresh, hopefully preserving the integrity of the data stored in that row. Similarly, even if the DRAM device repeatedly and frequently transitions between self-refresh mode and operational mode, as in the case depicted in FIG. 2, at least one row will be refreshed with each transition.
Unfortunately, the JEDEC suggestion has its shortcomings. First, because the JEDEC suggstion is a programming convention which depends on programmers actually and religiously including the mandated auto-refresh command in their programs. Accordingly, the JEDEC suggestion is often ignored by programmers, causing the problems previously described. Second, the JEDEC approach wastes time. Under the JEDEC approach, the system first must wait for the passage of the interval txsrjust in case a row was being self-refreshed at that moment the self-refresh exit command was issued; then, resumption of read and write operations is further delayed by the time it takes to complete an auto-refresh of the next row. At least one of those intervals represents a pure waste of time. If a row was being refreshed when the self-refresh command was issued, then auto-refresh of the next row—and the time required to complete it—was unnecessary. On the other hand, if a row was not being refreshed when the self-refresh command was issued, then waiting the interval txsr for such a coincidental, hypothetical row refresh to complete was wasted.
FIG. 3A illustrates the time wasted using the JEDEC convention using a timing diagram of a system entering and exiting a self-refresh mode pursuant to this approach. Specifically, FIG. 3A shows the state of the CK 310, CK* 315, and CKE 320 signals, and the present command 325. Between times T0330 and T1340, the CKE signal 320 is driven low, directing the memory device into self-refresh mode which the memory device enters at T1340. The self-refresh mode continues until between times Ta0350 and Ta1360, when the CKE signal 320 is driven high, directing the memory device to exit the self-refresh state. In the event that a row refresh was being executed at the time the device was directed to exit the self-refresh state, the device is permitted a wait state to allow that refresh to be completed. The system issues a null, NOP command at Ta1360 allowing this interval to pass. After the conclusion of that transitional period txsr, the memory device is potentially available for read and write operations at Tb0370. However, in accordance with the JEDEC approach, before useful read and write operations should be conducted, the system first issues an auto-refresh command at Tb0370 to compensate for any refresh cycles that were lost while the memory device transitioned. In other words, after the self-refresh mode is terminated, the system must allow two intervals to pass upon exiting self-refresh: the waiting interval, txsr, and the time required to perform an auto-refresh operation, trfc.
In sum, devices currently used may not refresh rows of memory cells sufficiently rapidly upon switching between self-refresh and operational modes, and the contents of those memory cells could become corrupted. This problem currently is addressed by programming conventions. However, these programming conventions require that programmers actually implement the conventions, and they also waste time in mandating potentially unnecessary row refreshes at the conclusion of mandated transitional waiting intervals. It is to this concern that the present invention is directed.